Multicast technology makes it possible to send data from a single source to many recipients through a data network, without having to set up unicast communication, i.e. one-to-one individual communication between the source and each of the recipients. To that end, the source sends data, in data packet form, to a single address associated to a multicast group to which the equipment interested in being recipients of the data sending can subscribe. This address referred to as a multicast address or also as a multicast group address, is an IP (Internet Protocol) address chosen within a range that is reserved for multicast applications. The data packets which have been sent by the source to the multicast address are then replicated in the different network routers so that they can reach the recipients that have joined the multicast group.
The recipients that receive data in a multicast group are usually, but not always, equipment connected to the data network by means of a proxy or a router. Hereinafter, the term “host” will be used to refer to the recipient equipment. A host can be, for example, a computer, a set-top box (digital signal decoder) connected to a television set, or any other device capable of receiving data packets.
When a host wants to receive the information sent by one or several sources of a multicast group, it usually sends via a router or an intermediate proxy a subscription message to subscribe to the group so that the router transmits to it the data arriving through the data network and which has been sent by the sources of the multicast group. Likewise, when a host wishes to stop receiving data packets from a multicast group, it usually sends via the router or the proxy an unsubscribe message to stop receiving the data packets.
The messages exchanged between a host and a router to manage membership to a multicast group generally use the IGMP protocol (Internet Group Management Protocol) or the MLD (Multicast Listener Discovery) protocol, according to whether or not the router works with version 4 (IPv4) or version 6 (IPv6) of the IP protocol (Internet Protocol), respectively. When there is a proxy between the host and the router, the proxy also uses the IGMP/MLD protocols to exchange with the host, the closest router or other intermediate proxy, the multicast group membership messages. In these cases, the proxy can receive from different hosts requests to subscribe to or to unsubscribe from a multicast group, and it assembles them to thus reduce IGMP/MLD message traffic it sends to the router. Hereinafter, the generic term IGMP proxy will be used to designate a proxy using the IGMP/MLD protocols.
FIGS. 1, 2, and 3 show different messages used in the IGMPv3 (IGMP version 3) protocol. FIG. 1 shows a “Membership Query Message” which is a message sent by IGMPv3 routers to the hosts so that the hosts respond with messages that indicate the multicast traffic that they wish to receive. FIG. 2 shows a “Membership Report Message” which is a message sent by the hosts to the routers to indicate the multicast traffic that they wish to receive. This information sent by the hosts in the Membership Report type messages is organized into different blocks of data referred to as “Group Records”. The structure of these group records is shown in FIG. 3.
In addition, routers exchange messages with one another for the purpose of defining the routing which allows efficient routing of the data from the sources to the hosts that have subscribed to a multicast group. To that end, the routers use specific protocols, including the very well known PIM-SM (Protocol Independent Multicast—Sparse Mode).
In summary, the routers receive from the hosts, in the form of IGMP/MLD messages, information specifying which multicast groups they want to receive traffic from, and they communicate with other routers, for example by means of the PIM-SM protocol, for the purpose of setting up a routing which takes the traffic requested by the hosts to such hosts. All of the aforementioned protocols are defined and documented by the Internet Engineering Task Force (IETF).
The IGMP protocol version currently being used is IGMPv3, which is described in the RFC 3376 specifications published on line by the IETF (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments 3376, October 2002; currently available at Internet address http://tools.ietf.org/html/rfc3376).
With regard to the MLD protocol, the version currently being used is MLDv2, which is described in the RFC 3810 specifications published on line by the IETF (R. Vida et al., Engineering Task Force, Network Working Group, Request for Comments 3810, June 2004; currently available at Internet address http://tools.ietf.org/html/rfc3810).
The operation of an IGMP proxy is described in the RFC 4605 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, August 2006; currently available at Internet address http://tools.ietf.org/html/rfc4605).
The PIM-SM protocol used for the communication between routers is described in the RFC 4601 specifications published on line by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, August 2006; currently available at Internet address http://tools.ietf.org/html/rfc4601).
Multicast technology was initially implemented primarily to be applied to the many-to-many communication model, known as ASM (Any Source Multicast), in which many users communicate with one another and any of them can send data and also receive data from everyone else. A typical ASM application is multiparty calling via Internet. Multicast technology was then implemented to be applied to the one-to-many communication model known as SSM (Source Specific Multicast), in which a single source sends data for many recipients.
In earlier IGMP protocol versions, a host could not choose the data sending sources it did not want to subscribe to within a multicast group, rather the host could only subscribe to or unsubscribe from the group for all the sources. The messages a host sent to a router were very simple: Join (G) to receive traffic from the multicast group G and Leave (G) to stop receiving it. Therefore, earlier IGMP protocol versions did not allow SSM. The possibility that the hosts could choose the sources within a multicast group was introduced in the IGMPv3 version of the IGMP protocol to allow SSM. To that end, a host can send IGMP messages containing data blocks referred to as Group Record in which the host defines the sources from which traffic is to be received for each multicast group. These Group Record data blocks in an IGMP message can be of several types:                An INCLUDE type Group Record data block containing information on source IP addresses from which the host wishes to receive data sending. According to the terminology of the RFC 3376 specifications, the sources chosen by means of an IGMP message containing an INCLUDE type Group Record are referred to as INCLUDE sources.        An EXCLUDE type Group Record data block, containing information on source IP addresses from which the host does not wish to receive data sending. In this case, it is interpreted that the host wishes to receive data sent by all the sources of the multicast group except the sources indicated as excluded in the message. According to the terminology of the RFC 3376 specifications, the excluded sources by means of an IGMP message containing an EXCLUDE type Group Record are referred to as EXCLUDE sources.        
Channel (S, G) is used hereinafter, and according to the common nomenclature in SSM technology, to refer to the sending of source S of the multicast group G.
In the third version of the IGMP protocol (IGMPv3) it was decided that for a multicast group each network interface can only operate in one of the following modes, being able to pass from one to another: the INCLUDE mode, where the network defines a list of INCLUDE sources, or the EXCLUDE mode, where the network defines a list of EXCLUDE sources. The RFC 3376 specifications describe a method with which the hosts can select the multicast traffic that they wish to receive. A brief summary of this operation is provided below.
Paragraph 2, entitled “The Service Interface for Requesting IP Multicast Reception” of the RFC 3376 specifications describes a service interface that can be used by the upper network layers of the host protocols or the host programs in order to request that the IP network layer accept or reject the multicast traffic from certain multicast addresses. For this purpose, it uses a function known as IPMulticastListen.
The RFC 3376 specifications of the IGMPv3 explain that the systems must support IGMP messages as per the following function, which enables a host to choose the multicast data sources:    IPMulticastListen (socket, interface, multicast-address, filter-mode, {source-list})    where:    “socket” is a parameter used to distinguish the different applications that are executed on the system (for example, programs and processes) and which call to the IPMulticastListen function.    “interface” is a local identifier for the network card or network interface on which one wishes to receive the multicast traffic indicated in the call to the IPMulticastListen function. If it is wished to receive the same multicast traffic on more than one network interface, the IPMulticastListen function is called separately for each network interface.    “multicast-address” is the multicast group address.    “filter-mode” is the network interface mode, which may be INCLUDE or EXCLUDE. In the INCLUDE mode, the network interface defines the source-list as INCLUDE; this means that it wishes to receive the multicast group traffic sent by all the sources in the list. In the EXCLUDE mode, the network interface defines the source-list as EXCLUDE; this means that it wishes to receive the multicast group traffic from all the sources sent in the multicast group, except the sources in the list.    “source-list” is the INCLUDE or EXCLUDE source-list.
For a given socket combination, network interface, and multicast group, there can only be one “filter mode”, which may be INCLUDE or EXCLUDE.
The system stores a state record for each active socket. This register contains the following information:
(interface, multicast-address, filter-mode, {source-list})
For each socket, the “filter-mode” of the record can only be INCLUDE or EXCLUDE.
Likewise, the system stores a state record for each network interface and multicast group. This record contains the following information:
(multicast-address, filter-mode, {source-list})
Each network interface and multicast group has a state record storing the information on the interface and group and the state record contains a field referred to as filter-mode which can only be of the INCLUDE type, containing only INCLUDE sources, or of the EXCLUDE type, containing only EXCLUDE sources. The rules that are transcribed below are applied when the network interface record must result from the combination of different records:                Rule 1. If any of the data sources of a group G1 is EXCLUDE, then the network interface will have an EXCLUDE filter-mode for the group G1 and the source list of the network interface is the intersection of the EXCLUDE source lists minus the sources of the INCLUDE lists.        Rule 2. If all the sources are INCLUDE type sources, then the network interface will have an INCLUDE filter-mode for the group G1 and the source list is the union of all the INCLUDE sources.        
The hosts send IGMP messages to the routers via each network interface in order to request multicast traffic, and the content of the messages is typically derived from information in state records associated with given network interface stored in a memory of the computer system.
There are generally two types of events that may cause the host to send IGMP messages to the routers. These are the receipt of an IGMP Query message or a change on the status registers of the network interface caused by, for example, a call to the IPMulticastListen function or other application.
Routers using the IGMP and PIM-SM protocols store the multicast traffic information that they must transmit through each network. This information consists of storing, for each network interface of the router, state information about multicast channels (S,G) or multicast groups (*,G) for which there is at least one host interested in receiving this multicast traffic, with a timer associated to each channel or multicast group that indicates the time passed since the router received the last message requesting this multicast traffic.
Table 1, extracted from RFC 3376, summarizes the operation of a router according to the IGMPv3 protocol. In Table 1, the first column “State 1” shows the initial state of the record of the IGMP router; the second column “Message” shows the content of a Membership Report message received by the IGMP router; the third column “State 2” shows the state of the record of the IGMP router after having received the Membership Report message; the fourth and last column “Actions” shows the actions that the IGMP router carries out after having received the Membership Report message. Table 1 contains 12 rows respectively corresponding to 12 processes which each illustrates the operation of the router according to its initial state (column 1) and according to the messages it has received (column 2).
Table 1 relates to a specific network interface of a router executing the IGMPv3 protocol and to a specific multicast group G. Each network interface and multicast group G will have their own state records which will be affected by the messages that the IGMP router receives through the network interface relating to the group G. The following nomenclature has been used in Table 1:                (A+B) means the union of the sets of sources A and B.        (A*B) means the intersection of the sets of sources A and B.        (A−B) means the set of sources A minus the sources of A that are also found in B.        INCLUDE (A) indicates that the IGMP router has a record with INCLUDE filter-mode with a set of sources A.        EXCLUDE (X,Y) indicates that the IGMP router has a record with EXCLUDE filter-mode because there are EXCLUDE sources, wherein:                    X is the Requested List of EXCLUDE sources            Y is the Exclude List of EXCLUDE sources.                        GMI is a parameter referred to as Group Membership Interval containing a value of time. A value of 260 seconds is used by default.        T (S) is the source timer of source S.        GT is the Group Timer, i.e. the timer of the record for switching from EXCLUDE mode to INCLUDE mode.        SEND Q(G, S) means that the IGMP router sends a Group-And-Source-Specific Query message to the hosts to check if there is still a host interested in receiving the sendings from sources S of multicast group G. When this action is carried out, the IGMP router also reduces the timers of the sources S to the LMQT value. If the IGMP router receives in response a message showing interest in any of the sources S, it then initializes the value of the timers of the sources, for which there is an interested host, to an initial value equal to GMI.        DEL(A) means that the IGMP router deletes from the record the sources of list A.        LMQT is a parameter referred to as Last Member Query Time containing a time value. It is the time a host has to reply to a Group-And-Source-Specific Query type message which has been sent by the IGMP routers. After this time, if no host replies that it is interested in receiving the channels specified in the message, the IGMP router stops transmitting them. The value of LMQT in the IGMPv3 protocol is 20 seconds by default.        
The messages in column 2 of Table 1 are the six types of IGMP messages defined in the IGMPv3 protocol for indicating to the router the sources from which it wishes to obtain multicast traffic. The meaning of these six IGMP messages is described in RFC 3376 (chapter 4.2.12) and is as follows:                IS_IN (Z), IS_EX (Z) indicate that the network interface of the host that has sent the message has an INCLUDE or EXCLUDE filter-mode, respectively, for the sources of list Z.        TO_IN (Z), TO_EX (Z) indicate that the network interface of the host that has sent the message has switched the filter-mode from EXCLUDE mode to INCLUDE mode, or from INCLUDE mode to EXCLUDE mode, respectively, for the sources of list Z.        ALLOW (Z) indicates that the network interface of the host that has sent the message wishes to receive the traffic from the new sources of list Z. These sources are the sources that the network interface will add to its INCLUDE source list or they are the sources that it will delete from its EXCLUDE source list.        BLOCK (Z) indicates that the network interface of the host that has sent the message no longer wishes to receive traffic from the sources of list Z. These sources are the sources that the network interface will delete from its INCLUDE source list or they are the sources that it will add to its EXCLUDE source list.        
It can be seen that the 12 rows of Table 1 correspond to 12 combinations of an initial state record of the router (column 1) and of a type of IGMP message received (column 2). The router consults the hosts by means of a Group-And-Source-Specific Query message (SEND messages in column 4 of Table 1) for checking if there is a host interested in receiving multicast data from those sources, the traffic of which was being initially transmitted (column 1 of Table 1) and no longer wishes to receive according to the sources indicated in the last received IGMPv3 message (column 2 of Table 1).
The presence of switches on data networks is common, especially in “Local Area Networks” (LAN). A switch is an electronic network interconnection device that normally operates at layer 2 (the data link layer) of the OSI model (“Open Systems Interconnection”). The OSI model is the open systems interconnection reference model created by the ISO (“International Organization for Standardization”) and is known to one skilled in the art.
In computer networking, a “frame” or a “data frame” is a digital data transmission unit on the layer 2 of the OSI model. RFC 1122 defines a frame as “the unit of transmission in a link layer protocol, and consists of a link layer header followed by a packet”
A switch interconnects two or more network segments, passing data frames from one segment to another using the layer 2 destination address of the data frames (for example, the “MAC address” in Ethernet networks). In order to send the data frames to the devices connected to each one of its ports, a switch determines and stores the layer 2 address of each device connected to each of its ports.
The low-level protocol group most used on local area networks is currently the Ethernet protocol group, defined according to IEEE (“Institute of Electrical and Electronics Engineers”) specifications. Ethernet defines both the physical layer (layer 1) and the data link layer (layer 2) in the OSI model, and divides the data link layer into two sublayers: one layer known as LLC “Logical Link Control”) which is established in the IEEE 802.2 specifications, and a MAC (“Media Access Control”) layer, which is established in the different IEEE 802.3 specifications, such as IEEE 802.3u (“Fast Ethernet”) based on electric cabling, or IEEE 802.3z based on fiber-optics. There are also wireless Ethernet protocols, like IEEE 802.11, also known as WIFI, or IEEE 802.16 known as WIMAX.
The same LLC (Logical Link Control) protocol can be used with different MAC layer protocols since the IEEE establishes new MAC layer protocols without modifying the LLC protocol. This is one of the reasons for the success of Ethernet.
One of the functions of the MAC layer is to determine the physical addresses of the devices. Ethernet uses 6-byte physical addresses referred to as MAC addresses (“Media Access Control Address”).
The IEEE has identified three MAC address categories:                Unicast MAC addresses: these are MAC addresses that identify each individual network interface. Normally the address is determined by the hardware of each network card.        MAC broadcast address: this is the MAC address with 6 bytes having the value FFFF.FFFF.FFFF in hexadecimal format. If a data frame is sent to this address, all the network devices receive the data frame and must process it.        MAC multicast addresses: these are addresses used to transport multicast data packets. When IP protocol is used, a MAC multicast address takes the form 0100.5exx.xxxx in the hexadecimal system, where xx.xxxx may be a value between 00.0000 and 7f.ffff.        
Bit 0 of Octet 0 in an IEEE MAC address indicates whether the destination address is broadcast/multicast address or a unicast address. If this bit is set (value=1) then the frame is a broadcast frame or a multicast frame.
In the case of Ethernet IP multicast frames, all of them use MAC layer addresses that begin with the 24 bit prefix 01.00.5E.XX.XX.XX. But only half of these MAC addresses are avail-able for use by IP multicast. This leaves 23 bits of MAC address space for mapping the layer 3 IP multicast address into the layer 2 MAC address.
As there are only 23 bits to determine a MAC multicast address of a data frame, while the IPv4 protocol uses 28 bits to determine an IP multicast address in an IP data packet (the first 4 bits of an IP multicast data packet are always 1110 in binary notation), the 28 bits of the IP multicast address of an IP data packet must be transferred to the 23 bits of the MAC multicast address of the corresponding data frame. Therefore, 5 bits of the IP multicast address are lost in this process. The transfer is therefore made by transferring the 23 least significant bits of the IP multicast address to the 23 bits of the MAC multicast address. Hence, a single MAC multicast address corresponds to 32 IP multicast addresses.
Referring now to FIGS. 4 and 5, different types of layer 2 Ethernet packets or frames encapsulating a layer 3 IP packet are shown.
The preamble of an Ethernet frame consist of a 56-bit (7-byte) pattern of alternating 1 and 0 bits, which allows device on the network to easily detect a new incoming frame.
The Start Frame Delimiter (SFD) is the 8 bit value marking the end of the preamble of an Ethernet frame. It has the value 10101011. The SFD is designed to break the pattern of the preamble, and signal the start of the actual frame. The SFD is immediately followed by the destination MAC address.
Every Ethernet network card has a unique 48-bit serial number called MAC address, which is stored in ROM or EEPROM carried on the card. The MAC address identifies the device uniquely on the LAN.
The destination MAC address (DA) field indicates the MAC address of the network interface of the intended recipient of the packet. The DA field also indicates whether or not the packet contains a multicast or broadcast data. Other fields within the packet may also indicate whether the data is carrying is multicast or broadcast, for example the IP destination address when the payload is a IPv4 packet.
The Source MAC address field provides the identification of the node from which the data packet originated. It identifies the origin node using the MAC address of the network interface of the origin node.
The EtherType is a two octet field indicating the data type encapsulated in the payload (the frame data field). For example, an EtherType value of 0x0800 indicates that the payload contains an IPv4 datagram.
When the original Ethernet standard, developed by DEC, Intel and Xerox, went through a formal IEEE standardization process, the EtherType field was changed to a data length field in the new 802.3 standard. This standard required an IEEE 802.2 header to follow the length field to specify the packet type.
In order to allow packets using different versions of Ethernet framing in the same network, EtherType values must be greater or equal to 1536 (0x0600). That value was chosen because the maximum length of the data field of an Ethernet 802.3 frame is 1500 bytes. If the field's value is greater than or equal to 1536, the field must be an EtherType. If the field's value is less or equal 1500 it must be a length field. Values between 1500 and 1535 are undefined.
FIG. 4 shows an Ethernet packet 420 with a Length field 425. To create a Type field for frames that use the EtherType/Length field as Length field, either one or two additional headers 430 are added after the 802.3 header but before layer 3 header 411. For example, when sending IP packets 410 the Ethernet frame has two additional headers: an IEEE 802.2 Logical Link Control (LLC) header 431 and an IEEE Subnetwork Access Protocol (SNAP) header 432. FIG. 4 shows these additional headers in the field 421. The arrow 427 indicates that the structure of the field 421 is detailed in the element 430. Note that the SNAP header Type 435 has the same purpose, with the same reserved values, as the Ethernet EtherType field. The 802.2 LLC Header 431 comprise the DSAP field (Destination Service Access Point), the SSAP field (Source Service Access Point) and a control field indicated as CTL in FIG. 4. The SNAP Header 432 comprises the OUI field (IEEE Organizationally Unique Identifier) followed by the 2-octet TYPE field that is a protocol identifier like the ETHERTYPE field.
The data portion 422 includes the layer 3 IP packet. In FIG. 4 the data portion 422 is an IP packet 410 comprising an IP Header 411 and IP payload 412. Lines 413 and 414 in FIG. 4 indicate that IP packet 410 is encapsulated in data portion 422.
FIG. 5 shows an Ethernet packet 520 with an EtherType field 525. In this case there are no additional headers with the EtherType field indicating the type of data in the data portion 522. In FIG. 5 the data portion 522 is an encapsulated IP packet 410 as indicated by lines 513 and 514.
The Frame Check Sequence are the extra checksum characters added to a frame for error detection and correction
Although it is not technically correct, the terms packet and frame are sometimes used interchangeably within the art. The IEEE 802.3 standards refer to MAC frames consisting of the destination address, the source address, length/type, data payload and frame check sequence fields. The preamble and the Start Frame Delimiter (SFD) are together considered a header to the MAC frame. This header and the MAC frame are considered a packet.
FIG. 6 shows a router 600 (e.g., IGMP router) situated between a first network 610 and a second network 611. In the example of FIG. 6, the first network 610 is connected to the downstream network interface 602 of router 600, and includes three hosts (620, 630 and 640). The second network 611 is connected to the upstream network interface 601 of router 600, and includes four sources (650, 660, 670 and 680) that send data packets. Each of the sources and hosts have a network interface which are represented by elements 625, 635, 645, 655, 665, 675 and 685 in FIG. 6. Each of networks 610 and 611 may be of any of a variety of network types, such as, for example, an Ethernet, WIFI, or WiMAX network, or any other type of data network that uses a shared medium to transmit data.
Via their respective network interfaces 625, 635 and 645, the hosts 620, 630 and 640 may receive the multicast data frames (layer 2 of the OSI model) that transport the multicast IP packets (layer 3 of the OSI model) from the multicast channels (S1,G1) and (S3,G1) in the form of physical signals (layer 1 of the OSI model). When network interfaces 625, 635 and 645 receive a layer 2 data frame that transports an IP packet with a multicast destination IP address, such as an Ethernet data frame with a MAC multicast destination address, the network interfaces 625, 635 and 645 process the data frame and transmit its contents to an application of its respective host (e.g., an operating system application) which verifies the destination and/or origin addresses of the packet and decides whether or not the packet must be discarded or sent to one of the applications being run in the host.
As shown in FIG. 6, sources 650 and 670 send multicast data packets (represented by elements 691a and 693a, respectively) using a multicast address G1. These packets may be link-layer packets that encapsulate multicast IP packets having an IP multicast destination address. Data source 650 sends the multicast IP packets 691a of the channel (S1,G1) that are encapsulated in frames that use a link layer source address (e.g., a MAC address) of the network interface 655 of source 650 and the multicast link layer destination address corresponding to the multicast group address G1 using the lower 23 bits of the multicast group address G1 as explained before. Data source 670 sends the multicast IP packets 693a of the channel (S3,G1) that are encapsulated in frames that use a link layer source address (e.g., a MAC address) of the network interface 675 of source 670 and the multicast link layer destination address corresponding to the multicast group address G1.
In the example of FIG. 6, hosts 620 and 630 each send a message to router 600 to request multicast traffic from sources S1 and S3, respectively, with host 650 not wishing to receive any multicast traffic. The message from host 620 may be an IGMPv3 message requesting the traffic (S1,G1) coming from source 650, where S1 is the IP address of the data source 650 and G1 is a multicast group address used by data source 650 to transmit multicast traffic. The message from host 630 may be an IGMPv3 message requesting the traffic (S3,G1) coming from source 670, where S3 is the IP address of the data source 670 and G1 is a multicast group address used by data source 660 to transmit multicast traffic. When the IGMP router 600 receives the messages from hosts 620 and 630, it transmits to the network 610 via network interface 602 the multicast IP packets 691b and 693b corresponding to data packets 691a and 693a sent from channels (S1,G1) and (S3,G1), respectively.
A problem that exists is that each of the hosts 620, 630 and 640 in network 610 must devote processing resources to analyze all of the data packets transmitted in network 610 to determine whether to receive or discard the packets. In the example of FIG. 6, host 640 which is not interested in receiving any multicast traffic must nevertheless waste processing resources to analyze and subsequently discard multicast IP packets 691b and 693b. In a like manner, hosts 620 and 630 must each waste processing resources to analyze and subsequently discard multicast IP packets 693b and 691b, respectively.
If the multicast channel (S1,G1) is, for example, an IPTV channel transmitting at about 3 Mbps, the hosts 630 and 640 must analyze a vast number of IP packets every second in order to discard them. As more multicast traffic is circulating through network 610, more processing resources must be assigned by the hosts in order to discard the multicast traffic that they do not want. In addition to affecting processing operations of the hosts, the charge life of batteries that operate mobile computing devices, such as mobile phones, is also reduced.
Another problem associated with the operation of the data network system of FIG. 6 is that the sending of multiple IP multicast packets to network 610 is possible for the purpose of attacking and at least partially disabling the operation of one or more of hosts 620, 630 and 640.
Even in networks where multicast IP packets are sent from sources to hosts without an intermediary router, multicast filtering using either the layer 2 destination addresses or the layer 2 source addresses of frames. For example using the destination or source MAC address in Ethernet networks, there exists a problem since, for among other reasons, it does not permit source specific multicast filtering due to the fact that one multicast MAC address corresponds to 32 IP multicast addresses.
In a data network where a router is situated between the sources that send data and the hosts, source specific filtering is not possible using layer 2 filtering since the layer 2 source address of the multicast IP packets is lost during router processing. In FIG. 6, when router 600 receives in its upstream network interface 601 a link layer data packet containing an IP packet, for example the 691a and 693a multicast packets, the router removes the frame header and transmits the IP packet. In general, the routing process forwards only the IP packet and discards link layer headers and trailers along the way. When the router 600 transmits IP packets 691b and 693b of the multicast channels (S1,G1) and (S3,G1) to network 610 through its downstream network interface 602, the router 600 creates new link layer data packets to encapsulate the multicast IP packets. These new link layer packets use the link layer source address of the network interface 602 and use the multicast link layer destination address formed using the lowest 23 bits of the multicast group address G1. The link layer packets that encapsulate the IP packets of the multicast channels (S1,G1) and (S3,G1) use the same link layer destination address and the same link layer source address.
When the hosts 620, 630 and 640 receive the link layer data packets containing the IP multicast packets of the multicast channels (S1,G1), the link layer source address of the network interface 655 of source 650 is not present in the link layer packet because it was removed in the router 600. The same happens with the link layer packets containing the IP multicast packets of the multicast channel (S3,G1). That is, the link layer source address of the interface 665 is lost during the routing process. For this reason, when a multicast IP packet goes through a router It is not possible to filter the multicast traffic of a multicast group from different sources using the link layer destination address or the link layer source address.
In other words, when source specific multicast is used, source specific multicast traffic filtering by a host cannot be accomplished using layer 2 filtering because in source specific multicast the IP source address for the multicast traffic that a host wishes to receive is only located in the IP header of the IP packet when the multicast traffic is transmitted through a router. Prior art host network interfaces that use the multicast MAC destination address for filtering multicast traffic have very limited filtering capability. As an example and with continued reference to FIG. 6, when the network interfaces of host 620, 630 and 640 filter the multicast traffic of the group G1 using the corresponding multicast MAC address, the multicast traffic from all the sources 650, 660, 670 and 680 of group G1 are filtered along with the multicast traffic from all the sources for the other 31 multicast group addresses that have the same lowest 23 bits as the lowest 23 bits of the multicast group G1.